Megahits 3

home *** CD-ROM | disk | FTP | other *** search

/ Megahits 3 / Megahits 3 (1994)(GTI - Rhein-Main-Soft)(DE)[!].iso / denkspiele / amancala / english / amancala.doc < prev next >

Wrap

Text File | 1994-10-14 | 17KB | 382 lines

A M A N C A L A V 1 . 1 9 ============================= Thorsten Koschinski Meisenweg 10 W-2082 Uetersen Germany 1. COPYRIGHT AMancala V1.19 (C) Thorsten Koschinski 1991. All rights reserved. Except for Requester.Library V 2.5 and all it concerning files (C) Colin Fox and Bruce Dawson 1989. AMancala V1.19 is a reduced demo version of the ori- ginal Shareware program. This means that you can copy it freely as long as you respect the following rules : 1. No fee is charged for the distribution of this package (except for postage and costs for magnetic media). 2. The program and all files belonging to it remain in their original unmodified form. 3. The package is always and only disribu- ted in its complete form. 2. DISTRIBUTION All releases of AMancala higher than V 1.19 are Share- ware. These versions can be obtained directly by the author by discharging a fee. This charge amounts to $20 for Western Europe and $25 for all other countries. Also all other saleable international currencies will be accepted, so far as the amount equals to the actual official rule of exchange of the dollar. Additional costs for postage dropped. Each so recorded user gets the newest release of the program including a detailed manual on disc and becomes a registered user. We offer an update service for one year to all registered users. 3. DISCLAIMER Although every effort has been made to have a correct function depending on the description in the manual, the author is not responsible for any damage the use of this program does and expresses no warranty on the faultlessness of the game and the whole package. You are entirely responsible on your own risk for all things sustained by the legal use or misuse of the files containing this package. 4. REQUIREMENTS AMancala V1.19 runs on all Amiga models with at least 512k byte of memory. The precise usage of memory in the english version amounts to 269048 byte Chip memory and 35280 byte Fast memory. The program runs as well on the Workbench (start by clicking the AMancala icon) as on CLI (input the name AMancala). As additional files the delivered fonts and the file req.library are required (see also Installation). When using AMancala with other applications in multitasking mode you take notice that, depending on the use of functions from the Requester.Library, all system requester will appear on the AMancala screen. 5. INSTALLATION Bevor you start the game it is necessary to install a couple of required files. This work is done by a batch file. This file installs two new fonts in the logical device FONTS: so far as they do not exist. It concerns the fonts Sapphire with the size of 19 and AMancala with the size of 16. In addition to this the file req.library is established in the logical de- vice LIBS:. The installation must be done only for one time. You can choose between an installation from Work- bench (clicking the Install icon) or from the CLI (In- put : Install<RETURN>). 6. THE GAME AMancala, originally Mankalla [ arab. : naqala = move away, displace ] is a boardgame, which is wide-spread in Africa, S-, SE-, and W.-Asia as well as in W.-India. Originally it was played on a simple board or with in the ground imbedded holes. In addition to the original name the game is also known under numerous other desig- nations, i.e. Manqala, Minqala, Mbao or Warri. The lat- ter two names denote towns sited in Africa, in which the game probably originated or at least got a great propagation. Mbao [ frc. mba'o ], is a town in the north eastern suburb region of Dakar in Senegal. Warri is a seaport in Nigeria, sited in the western delta of the Niger Ri- ver 80 km SSE of Benin City. In the history of origins also the tribe of the Baga, which is dominiciled at the coast of Guinea nor- thern from Conakry, emerges again and again. The mem- bers of this tribe could be supposed to be the creators of the game. The African originators played Mankalla with 6 sto- nes in each field. Possible are also variations with more or less stones per field. 3 or less stones don't make any sense, because therefor exist guaranteed stra- tegies of victory. Conceivable are also variants with more fields for each player or with more than two play- ers. 7. RULES OF THE GAME The below listed rules of the AMancala implementation differ in 2 details from the original. These modifica- tions will be listed at the end of the description of the rules and the reason for this deviation will be outlined. Each player owns 6 fields with 6 stones on each field and a so called Khala, where you have to collect stones. The 6 fields are comprehensive and clockwise grouped at the long side of the board. The Khala fol- lows in the sequence after the 6. field. The players perform their moves alternately. A move consists of the choice of one from your own 6 fields (by clicking with the left mouse button). The stone this field, the source, contains will be removed from it and distribu- ted among the other fields. This happens as follows : The distribution happens solitary clockwise. This means, that each field, sited to the right of the source, is additionally filled with one stone, respec- tively, until all stones taken from the source are con- sumed. Thus, the distribution covers first the own fields, following the own Khala, the opposing fields and again the own fields. It is possible, depending on the number of taken stones, to walk through the playing field more than once, so that some fields, including the source, could get more than one additional stone. Decisive for now is, in which field the last stone was placed. Three cases are to distinguish : 1. Last stone in own Khala --> Move complete. 2. Last stone in own fields --> Clear this field and distribute all containing stones as shown above at the fundamental move. With this possibility one can attain an arbitrary long chain of moves. 3. Last stone in an opposing field --> In this case it exists the possibility to plunder stones for your Khala. And that by the following procedure : Outgoing from the field, in which a stone is pla- ced at last, one looks at the adjacent field in decreasing direction (so far as it exists). Are there 2 or 3 stones, they will be removed and pla- ced in the own Khala. Subsequently one handles the same with the next field in decreasing order. Sto- nes will be removed as long as the inspected field contains 2 or 3 stones or no field with a lower number exists. The winner is, who - first has collected more than 36 stones in his Khala. - has no stone left in all his fields (in this case he gets all stones placed in the fields of his op- ponent, too). Finally we discuss, as mentioned above, the two mo- difications from the original rules. The first modification affects the linkage of moves. After the last stone is placed in a field of the moving player, all this field containing stones can, depending on the in this version implemented rules, be removed and distributed among the other fields. The original limits this variant in so far as that during a move stones must have been layed up at the opposing side. By this, in my opinion, the tactical freedom of action will be dramatically restricted. Also the original rule offers the moving player less possibilities to protect fields, which are low on stones, from capturing by the opponent. Moreover the final stage would degenerate to a tedious moving of single stones without leaving the possibility to the behindhand player to repair his lag. The second modification affects the capturing of op- posing stones. In the original it is provided, that stones can be already captured from the field, in which the last stone was distributed. This rule would allow to clear all fields of the opponent in one move. This success however is misleading, because such a move would only lead to victory, if it is sufficient to con- centrate more than the half of all stones in the own Khala. If this is not the case, the opponent wins - without doing anything productive - on his next move, since indeed all his fields are empty. One could think that it is in the responsibility of the player to avoid such a situation, but still a beginner should be pro- tected from such 'unlogical' situations by the rules. That is why in this implementation the field, in which a stone is placed at last, is locked from capturing, so that at least one field remains filled. By this it is not complete ensured, too, that the capturing player becomes a game decisive disadvantage (suppose that only field no. 6 remains with less than 8 stones. These sto- nes could be distributed to gain the victory in the following move on the own Khala and the opposing fields, so that the own fields remain empty), this me- thod however ensures rather a course of the game con- curring with the rules. 8. ERROR MESSAGES If the program finds an environment, in which it can not be run, it ends and prints out a short error mes- sage, which will be sufficient in most cases to elimi- nate the incorrect situation. The essential faults arise when there is a lack of memory, libraries or other files. The most frequently arising faults depend on an ab- sence of a preceding installation as described at 5. Here now a condensed collection of all existing error messages : a. Can't open Req.Library The program can't find the Requester.Library in the logical device LIBS:. Probably the installation has not been done until now or proceeds in an incorrect manner. b. Can't open Intuition.Library This error should never happen, because the Amiga operating system serves that the Intuition-Library stays always resident in memory. c. Can't open Graphics.Library Also this error should never occur, because the Ami- ga operating system handles the Graphics-Library in the same manner as the Intuition-Library. d. Can't open DiskFont.Library The DiskFont.Library doesn't exist in the logical device LIBS:. This file may be included on every original Workbench disc and can be copied from here to your system disc or harddisc. e. Can't open Screen The reason for the occurence of this error message is a critical lack of memory. Clean the RAM memory of your Amiga until you get enough memory as descri- bed at 4. f. Can't open AMancalaWindow see e. g. Can't open ProtocolWindow see e. h. Can't open WarningWindow see e. i. Can't find AMancala-Font The AMancala font with the size of 16 doesn't exist in the logical device FONTS:. Probably the installa- tion has not been done until now or proceeds in an incorrect manner. j. Can't find Sapphire-Font The Sapphire font with the size of 19 doesn't exist in the logical device FONTS:. Probably the installa- tion has not been done until now or proceeds in an incorrect manner. k. Can't find Topaz-Font The Topaz font with the size of 8 wasn't found. Un- til including Kickstart 2.0 this font should stay resident in memory. l. No memory for AMancalaWindow background area see e. m. Can't attach temporary RastPort for AMancalaWindow see e. n. No memory for ProtocolWindow background area see e. o. Can't attach temporary RastPort for ProtocolWindow see e. p. No memory for WarningWindow background area see e. q. Can't attach temporary RastPort for WarningWindow see e. 9. MANUAL For this demo version no manual exists. Nevertheless the online manual of the game should supply enough in- formation. However the obtainable Shareware releases enclose a comprehensive, all details explanatory manual, which will be supplied on disc. 10. LIMITATIONS The release 1.19 belonging to this document contains a slightly reduced set of functions compared with the ac- tual Shareware release. The main difference is the loss of the possibility to save and print protocols. Also the game will be afflicted in continually shor- ten distances by distasteful pauses, which will getting longer with increasing duration of the game. At this it is not a matter of chicanery against the user, neither the gambling fever should be reduced, but it is necessary to adhere the idea of Shareware. The Shareware package proper additionally contains a from the game separated program, to view and print out protocols independent from this. 11. FUTURE IMPROVEMENTS For the releases 1.2x published approximately from September 1992 we have planed some enhancements. For the first time environment variables will be used to self configure the program in several places. Adjust- able should be for instance the colors, the directory, which contains the file with the ranking lists, the ex- tention of the protocol files and some things more. Furthermore additional icons will be produced, when saving a protocol. An independent program serves for viewing at and printing out protocols without the help of the main program. For use of the game with faster Amiga models (A3000, Turboboards) the number of playable computer types will be adequate extended. Also possible is an enhancement about a playing mode depending on the original rules. Whether this mode will be offered alternatively or will replace the current one is not decided until now.